home *** CD-ROM | disk | FTP | other *** search
/ TeX 1995 July / TeX CD-ROM July 1995 (Disc 1)(Walnut Creek)(1995).ISO / tex-k / tex-k-archive.past / tex-k-archive.gz / tex-k-archive / 000382_fj@iesd.auc.dk_Mon Mar 14 18:15:53 1994.msg < prev    next >
Internet Message Format  |  1994-10-11  |  5KB
  1. Received: from iesd.auc.dk by cs.umb.edu with SMTP id AA24759
  2.   (5.65c/IDA-1.4.4 for <tex-k@cs.umb.edu>); Mon, 14 Mar 1994 11:16:36 -0500
  3. Received: from loke.iesd.auc.dk (loke.iesd.auc.dk [130.225.48.20]) by iesd.auc.dk (8.6.5/8.6.5) with ESMTP id RAA26869; Mon, 14 Mar 1994 17:16:31 +0100
  4. From: Frank Jensen <fj@iesd.auc.dk>
  5. Received: from localhost (fj@localhost) by loke.iesd.auc.dk (8.6.4/8.6.4) id RAA16044; Mon, 14 Mar 1994 17:15:53 +0100
  6. Date: Mon, 14 Mar 1994 17:15:53 +0100
  7. Message-Id: <199403141615.RAA16044@loke.iesd.auc.dk>
  8. To: kb@cs.umb.edu
  9. Cc: tex-k@cs.umb.edu
  10. In-Reply-To: <199403141051.AA28714@terminus.cs.umb.edu> (kb@cs.umb.edu)
  11. Subject: Re: Kpathsearch -- database searching
  12.  
  13. >        setenv TEXINPUTS .:~/TeX/inputs:</usr/local/lib/texmf/ls-R>
  14. >
  15. > That's an interesting idea (putting the db's into the search path).
  16. > However, I'm not sure it's the best solution, since it requires the user
  17. > to know whether or not there is a database, at path-specification time.
  18. > If we can just dynamically use it if it's there, and not use it if it's
  19. > not, with the same path specification, that seems preferable to me.
  20.  
  21. In practice, I don't think there is a problem.  In my case, I would
  22. compile the following default path into virtex:
  23.  
  24.     ".:</usr/local/lib/texmf/ls-R>"
  25.  
  26. and I would set my environment variable as follows:
  27.  
  28.     setenv TEXINPUTS .:~/TeX/inputs:
  29.  
  30. (perhaps omitting `.')  So the ordinary user doesn't have to worry
  31. about db files (unless he wants to create his own hierarchy and build
  32. a db for that).
  33.  
  34. I think it boils down to a trade-off between ease of use and how fine
  35. control over the search scheme we want to be able to specify.
  36.  
  37. > Instead, I was thinking of differentiating searches for files that must
  38. > exist (PK's, TFM's, \input's) from those which need not (VF's in xdvi,
  39. > \openin's).
  40.  
  41. > In the former case, if a file can't be found in the db, we'll look for
  42. > it on the filesystem (in case it's been created since after the db was
  43. > last updated).
  44.  
  45. > For the latter, if a file isn't in the db, we skip looking for it on the
  46. > filesystem -- cmr10.vf isn't going to exist, and we don't want to expand
  47. > $TEXMFROOT//fonts looking for it. (Except (of course) we look on the
  48. > filesystem if the db file doesn't exist at all!)
  49.  
  50. It is, of course, possible to differentiate between files that are
  51. supposed to exist and files that are not.  The question is how to make
  52. this differentiation: Is it simply built into the code that files
  53. found in a certain path (e.g., TEXINPUTS) are supposed to exist?  Or
  54. do we provide some way to configure Kpathsearch, i.e., a way to tell
  55. it that certain paths (or even certain parts of the paths) are
  56. supposed to be searched by db only.
  57.  
  58. I prefer the latter approach.
  59.  
  60. > It's true that this loses for files that can be dynamically generated
  61. > (cmr10.600pk), since we will look on the filesystem for them, fail, then
  62. > generate them. But this is happens only once (or until tomorrow, at
  63. > most), since as soon as the db is regenerated (hmm, maybe maketexpk
  64. > should regenerate the db?) it'll found that way.
  65.  
  66. Yes, maketexpk should do that (and xdvik/dvipsk should reread the db).
  67.  
  68. > On a typical run, which doesn't involve dynamically creating any files,
  69. > there should be no lengthy filesystem operations given an up-to-date db.
  70.  
  71. > By the way, there's a bug in the current sources -- if you have a file
  72. > ./foo.tex and <system dir>/foo.tex, and foo.tex is in the db, your path
  73. > spec is .:<sysdir>, and foo.tex is not the first file to be looked
  74. > up, <sysdir>/foo.tex will be found instead of ./foo.tex.
  75.  
  76. Yes, I had realized that!
  77.  
  78. But I thought that was your deliberate choice.  And, in fact, my first
  79. mail was directed at this point (perhaps that wasn't clear?).
  80.  
  81. As I wrote:
  82. >> I gather from the sources that the intent is to take each path element
  83. >> in turn, concatenate it with the file name being searched for, and
  84. >> match the result against each absolute path associated with the file
  85. >> name in the database (although the current match function is somewhat
  86. >> simplistic ;-).
  87.  
  88. If the match function hadn't been so simple, it would (should) never
  89. have matched the `.' with any of the paths in the db.  So for a file
  90. `foo.tex' that exists both as `./foo.tex' and as `<system dir>/foo.tex',
  91. Kpathsearch would first try to match `./foo.tex' with the paths found
  92. in the db and would fail since all the paths in the db begin with `/';
  93. then Kpathsearch would look on the disk and find it; so Kpathsearch
  94. would never search for `<system dir>/foo.tex'.
  95.  
  96. [This is exactly how the `path_search' function in Kpathsearch 1.7
  97. would have acted given a better `match' function.]
  98.  
  99. However, that would still not be good enough for me.  A consequence of
  100. this scheme would be that non-existing files would be searched for on
  101. the disk, including the system directory hierarchy.
  102.  
  103. This is the reasoning that lead me to propose the extended syntax with
  104. explicit indication of db/non-db search.
  105.  
  106. /Frank